Skip to content

Fix PictureBox frame callback handle race in OnFrameChanged - #14826

Open
LeafShi1 wants to merge 1 commit into
dotnet:mainfrom
LeafShi1:Fix_14823_pictureBox_animated_frame_callback_race
Open

Fix PictureBox frame callback handle race in OnFrameChanged#14826
LeafShi1 wants to merge 1 commit into
dotnet:mainfrom
LeafShi1:Fix_14823_pictureBox_animated_frame_callback_race

Conversation

@LeafShi1

@LeafShi1 LeafShi1 commented Jul 30, 2026

Copy link
Copy Markdown
Member

Fixes #14823

Root Cause

During animated image updates, OnFrameChanged could evaluate InvokeRequired before checking IsHandleCreated.
In rare timing windows (handle create/destroy while animation callback is running), this can lead to unstable handle state and an occasional "Error creating window handle".

Proposed changes

  • In PictureBox.OnFrameChanged, check IsHandleCreated first, then InvokeRequired.
    This allows for an immediate short-circuit when the handle does not exist, avoiding the more complex InvokeRequired path (which involves parent chain traversal, thread checks, and race conditions regarding handle state).
    It also ensures consistency with similar controls, such as Label and ButtonBase, which likewise check IsHandleCreated first.

Customer Impact

  • Reduces intermittent "Error creating window handle" for apps using animated images in PictureBox.

Regression?

  • No

Risk

  • Minimal

Test methodology

  • Manually

Test environment(s)

  • .net11.0.0-preview.7.26365.101
Microsoft Reviewers: Open in CodeFlow

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

This PR addresses an intermittent Win32Exception: Error creating window handle seen during PictureBox animated image frame callbacks by reducing handle-state race exposure in OnFrameChanged.

Changes:

  • Reordered the conditional in PictureBox.OnFrameChanged to check IsHandleCreated before evaluating InvokeRequired, avoiding the more complex InvokeRequired path when there is no handle.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

@SimonZhao888

Copy link
Copy Markdown
Member

Looks good to me!

@ricardobossan ricardobossan left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ALL LGTM!

@KlausLoeffelmann

Copy link
Copy Markdown
Member

There is one request in general I have:

Let's please create a document with breaking changes. And I mention this in this context, since we need to make sure, that we pursue different approaches to transfer knowledge to Copilot Agents in the right moment and context, so - for example - if they are tasks with a migration from NetFx to a .NET based TFM, they also take new options and most of all changed behaviors into account.

What has this to do with this PR? Well, this is a bug fix, but one which is also present in NetFx. So even if it is niche, it's automatically a potential breaking change, and that should be enough to include it in the list. If it then really has the potential to affect what a Copilot-driven migration/modernization would yield is bottom line for the Agent in charge to decide. But it needs to knowledge to base its decision on. And that's why we need that centralized information, which should become part of the WinForms repo.

This is not a call to action for now to anybody.
Just important information, everyone should be aware off, FWIW.
I will follow-up on this topic with concrete suggestions how to approach this!

@Shyam-Gupta, @Olina-Zhang, @LeafShi1, @SimonZhao888, @ricardobossan.

@LeafShi1

LeafShi1 commented Aug 7, 2026

Copy link
Copy Markdown
Member Author

There is one request in general I have:

Let's please create a document with breaking changes. And I mention this in this context, since we need to make sure, that we pursue different approaches to transfer knowledge to Copilot Agents in the right moment and context, so - for example - if they are tasks with a migration from NetFx to a .NET based TFM, they also take new options and most of all changed behaviors into account.

What has this to do with this PR? Well, this is a bug fix, but one which is also present in NetFx. So even if it is niche, it's automatically a potential breaking change, and that should be enough to include it in the list. If it then really has the potential to affect what a Copilot-driven migration/modernization would yield is bottom line for the Agent in charge to decide. But it needs to knowledge to base its decision on. And that's why we need that centralized information, which should become part of the WinForms repo.

This is not a call to action for now to anybody. Just important information, everyone should be aware off, FWIW. I will follow-up on this topic with concrete suggestions how to approach this!

@Shyam-Gupta, @Olina-Zhang, @LeafShi1, @SimonZhao888, @ricardobossan.

That makes sense.

I agree that even long-standing .NET Framework behaviors that appear to be edge cases should be tracked when fixed, as they may become migration-relevant breaking changes.

Centralizing this information would also allow future modernization tooling and Copilot-driven migration workflows to take such behavioral differences into account when assessing or upgrading applications.

I've added the ReleaseNotes-breaking-change-NetFx label to this PR so it can be tracked.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

releasenotes-breaking-change-NetFx Breaking change in behavior from NetFx, to be mentioned both in release notes and docs!

Projects

None yet

Development

Successfully merging this pull request may close these issues.

"Error creating window handle." From PictureBox.OnFrameChanged

5 participants